Shareware Grab Bag

home *** CD-ROM | disk | FTP | other *** search

/ Shareware Grab Bag / Shareware Grab Bag.iso / 007 / envsize.arc / ENVSIZE.DOC < prev

Wrap

Text File | 1986-05-15 | 38.9 KB | 1,255 lines

ENVSIZE Environment size control and display Documentation File A shareware product provided by: Charles P. Scott / Team Alpha 519 Garden Springs Dr. Mt. Sterling, KY 40353 (C) Copyright Charles P. Scott / Team Alpha, 1986 All rights reserved 1 Limitations on use and distribution This product is being distributed as shareware. This means that it can and should be distributed by any user who possesses a legitimate, unmodified copy and follows a few simple rules. At Team Alpha there are other products in the works which I hope will relieve some of the frustration of working with a PC. Needless to say, those products are somewhat more time consuming to create then ENVSIZE and will unfortunatly take some months yet. In the time untill they are available the facilities which have been created along the way could be getting some use by those who can use them. This gives others a chance to benifit and provides some contact for me with the users who will eventually be evaluating my other products. To this end my requests are simply: A. If you find this program and the information contained in the documentation of some value to you then please send fill out the registration form at the back of this document and send to: Charles P. Scott / Team Alpha 519 Garden Springs Dr. Mt. Sterling, KY 40353 Or through Compuserve ( ID: 76556,3335 ) { Of course any small donations would be appreciated. } B. You may not charge any fee for this software or for it's distribution. This includes a "DISK FEE" or similar charge. C. You may not distribute any modified copy of this software or it's documentation as the results may somehow end up reflecting on my products. D. You may not copy or reproduce the documentation for any other propose than as a reference for a single legitimate user. E. You may not distribute this software or documentation as a part of any comercial package or for corporate or institutional purposes. I'm realy not as bad as it seems from all this. If you have a use for ENVSIZE which does not conform to the above restrictions, please contact me at the above address or call (606) 498-0181 during business hours. Since the Shareware concept was first introduced it has been very successful in distributing a wide variety of first class software and rewarding the authors who participate. Please take the time to distribute this software by passing it on in it's complete and original form to other "Computerists" and bulletin board systems. 2 If you would please bear with me, I would like to explain a bit about how this program came to be and why I chose this method of distribution. It seems that I have been struggling with the environment ever since installing the hard disk in my Deskpro and needed to achieve some degree of automation and control over the large number of programs and utilities. This all came to a crytical point when I installed my EGA and extended memory card which, so to put it, caught MS-DOS with it's pants down. The stop-gap patches I had made to COMMAND.COM which got me this far down the path to ruin became unreliable at best and a better solution was required. The technical reasons for all this are described later in this document and should prove to be enlightening for the more casual users. (You hard core computerists already have bruises on your forehead) So to further the cause I entered another interrupt level in my work and created ENVSIZE. Charles P. Scott / Team Alpha 3 Table of Contents ----------------- 1. Overview of Parameters and the Environment a) Basic introduction to Parameters and the Environment b) Primary and subsequent Command Processors c) Location of the Environment(s) in memory 2. Problems with using the environment 3. Solving the problem with ENVSIZE a) ENVSIZE command syntax b) Environment status display c) Adding space to the environment d) Batch execution of ENVSIZE 4. Technical Description of ENVSIZE 5. Associated problems and bugs in DOS a) Providing Environment space in a SHELL b) Avoiding the batch Parameter evaluation bug 6. Registering with Team Alpha 4 1. Overview of Parameters and the Environment a) Basic introduction to Parameters and the Environment In PC-DOS and MS-DOS a Parameter is a string of characters which has a name assigned to it and is stored in an area called the Environment. The information so stored in the Environment may be used by a batch process, DOS or may provide information to certain programs. These strings may be created and listed using the command "SET". An example of this is found below. List all Parameters currently in the Environment. C>set <- Typed by user COMSPEC=C:\COMMAND.COM <- Response from DOS PATH=c:\;c:\dos Enter a new Parameter into the Environment. C>set author=Chuck <- Enter new Parameter C>set <- List Parameters in Environment COMSPEC=C:\COMMAND.COM PATH=c:\;c:\dos AUTHOR=Chuck <- Parameter AUTHOR now listed Delete a Parameter from the Environment. C>set author= <- Delete AUTHOR parameter C>set <- Author no longer in Environment COMSPEC=C:\COMMAND.COM PATH=c:\;c:\dos The Primary Command Processor (COMMAND.COM) has access to the Environment and is allowed to make permanent changes to it's contents. In fact some Parameters are inserted or modified by commands other than SET Such as PROMPT and PATH. One Parameter, COMSPEC, is placed in the environment by the Primary Command Processor when the system is booted. This parameter is used by the command processor to locate itself on the disk when the transient portion of COMMAND.COM is overwritten by a program and needs to be replaced. PROMPT and PATH are accessed by their corresponding commands as shown below. 5 C>prompt=? <- Set the prompt text ?set <- Notice that prompt is "?" COMSPEC=C:\COMMAND.COM PATH=c:\;c:\dos PROMPT=? <- Prompt text stored here ?prompt <- Restore prompt to default C>set <- PROMPT deleted from Environment COMSPEC=C:\COMMAND.COM PATH=c:\;c:\dos Certainly all of the above is covered in most of the MS-DOS manuals and associated books but there is actually more to know about the environment and how to use it. b) Primary and subsequent Command Processors Before we can get into the problems with making extensive use of the environment and the need for the ENVSIZE program, it is necessary to understand where things are in memory and to some extent how they are organized. First of all we must understand that at any one time there may be multiple copies of the Environment and the Command Processor. When your PC is first turned on or is rebooted a sequence of events occurs which culminates with running a file called COMMAND.COM. This is the Command Processor. It displays a prompt on the display and waits for a command from the user (or a batch process). When a command is entered, the Command processor evaluates that command and initiates a sequence of events to perform the requested operation. This Command Processor, which is loaded when the system is booted, is called the Primary Command Processor and is located below any other programs in memory (with the exception of installed drivers, IBMBIO and IBMCOM). The command SHELL in BASIC allows a user to seemingly re-enter DOS and enter commands as if we had never run basic. In fact what has happened is that BASIC requested that the program COMMAND.COM (found by the Parameter COMSPEC) be run in the available memory above BASIC. This results in a secondary copy of the Command Processor which is not exactly like the original. Sure it seems to work the same but the Environment Parameters which can then be accessed with the SET command are a copy of the originals associated with the Primary Command Processor. As a result of all this any changes made to these Parameters will not be seen when you finally return to the Primary Command Processor. Also there is a difference in where this Environment is located in relation to the current Command Processor which restricts adding Parameters (I will explain how to avoid this problem later). Since many copies of the Command Processor and it's Environment may be in memory at one time, there can be a variety of ways that operation may be different from the Primary Command Processor. 6 A copy of the Environment and how to find it is also passed to each program as it is loaded and run. This allows application programs to read Parameters and modify them, although any changes will only be seen in a subsequent program or SHELL run from that program. c) Location of the Environment(s) in memory At this point I think it would be wise to show how these things are located in memory and explain their limitations and the reasons for them. The following two memory maps show where the various components are located for just the Primary Command Processor and then with another program running. 1) Primary Command Processor Only ************************************* 0k * * * INT vectors and System Info. * * * ************************************* * * * IBMBIO, IBMDOS & Device Drivers * * * ************************************* * * * Primary Command Processor * * * ************************************* * Primary Environment * ************************************* * * Free memory space * * ************************************* End of RAM Note: The Environment Follows the Command Processor. 7 2) Primary Command Processor and another program ************************************* 0k * * * INT vectors and System Info. * * * ************************************* * * * IBMBIO, IBMDOS & Device Drivers * * * ************************************* * * * Primary Command Processor * * * ************************************* * Primary Environment * ************************************* * Program Environment * ************************************* * * * Program * * * ************************************* * * Free memory space * * ************************************* End of RAM Note: The program and the Command Processor Environments are boxed in and can't expand. 8 2. Problems with using the Environment By looking at at the charts above it can be seen that when only the Primary Command Processor is loaded, and there are no other programs (including resident programs) in memory, the highest occupied area of memory contains the Environment. This means that the Environment has room to be expanded when the space required for the Parameters being entered (via the set command, PROMPT or PATH) exceeds the size of the environment. As far as I know, all versions of MS/PC-DOS start with an environment size of 10 paragraphs (160 bytes). A quick calculation indicates that this is a fairly small space for even modest use of the environment. Since there is some overhead in the Environment, such as a null (0) between each Parameter and a double null after the last one, this really amounts to about five Parameters of thirty characters each, and that has to include the Parameter names and an "=". Needless to say we will generally require more space. Fortunately when no other programs follow the Command Processor the Environment is free to expand and will as required. The real problem occurs when another program is loaded after the Primary Command Processor. Looking at our second chart we see that there is no longer room for expansion of the Command Processor's Environment. Most PC users have in their software arsenal at least one "resident" program and many users automatically load at least one with their AUTOEXEC.BAT file. For those people there has been no hope of using any more than a very few Parameters. Even if you decide not to load resident programs at boot-up, there is a limitation to how much may be entered into the environment by the AUTOEXEC batch process. The reason is that a small block of memory (between 4 and 6 paragraphs) is allocated for management of a batch process and it is placed in the next available memory space, right smack at the end of our 10 paragraph Environment. If you don't believe me just try using a batch file to place a number of Parameters into the Environment and you will see the limitations. There seems to be only one conventional solution to this problem. That is to manually enter, at the keyboard, all of the Parameters required or enough Parameters to cause the Environment to expand to the required size. Use of "dummy" parameters (ie: set a=xxxxxxxxxxxxxxx) is about the best way of doing it. Then when the size is where you want it you will have to remove the dummy Parameters with the SET command to free that space up and then run a batch file to continue your start-up sequence. Fortunately the environment will not then contract on you. But what a royal pain! When a program or another copy of the Command Processor is loaded by DOS, a copy of the current Environment is placed in the first available memory and the program is loaded in the following space. The size of the Environment "copy" is only enough to include those Parameters in existence at that time. Because of this the new Environment is boxed in and has no chance of being expanded. When the loaded program is another copy of the Command Processor, use of the SET command to add 9 Parameters will, for the most part, be futile. Fortunately there is a hero in our story. In the sections to follow I will explain how to use the ENVSIZE program to expand the size of the Environment for the Primary Command Processor and how to secure space in other copies of the environment. 10 3. Solving the problem with ENVSIZE The ENVSIZE program has been created to help us solve the problems associated with what I consider to be reasonable use of the environment. It does this by expanding the Environment of the Primary Command Processor and reporting on the status of the current Environment. a) ENVSIZE command syntax There are two forms of command syntax for the ENVSIZE program. One to report on the status of the current Environment and the other to expand the Primary Environment size. If at any time you would like to review these commands on line simply type "ENVSIZE" as shown below. C>envsize Usage: envsize <paragraphs> ;add number of paragraphs envsize ? ;report size in paragraphs Note: there will also be a copyright notice and other information displayed. b) Environment Status Display ENVSIZE can provide information on the current Environment by simply entering "ENVSIZE ?". C>envsize ? Current environment statistics: Size in paragraphs.............(DEC)...... 10 Size in paragraphs.............(HEX)...... 000A Size in bytes..................(DEC)...... 160 Location of environment........(Segment).. 0F47 Location of command processor..(Segment).. 0E86 Current command processor is primary...... YES The size in paragraphs is reported in both Decimal and Hexadecimal for convenience. The locations of the Environment and the Command Processor make it easy to examine the environment with DEBUG and help to understand what exactly is happening. In the above example, for instance, the Environment is located higher in memory than the Command Processor. This is because the current Command Processor is the Primary copy. Therefore the above display would indicate that the Environment may yet be expanded (provided no resident programs exist). If the "ENVSIZE ?" command said that it was not the Primary Command Processor then the Environment would be located below the Command Processor and could not be expanded. 11 c) Adding space to the Environment To add space to the Environment associated with the Primary Command Processor simply enter "ENVSIZE n", where "n" is the number of paragraphs you would like to add to the current size (the present maximum is 256). C>envsize 10 Current environment statistics: Size in paragraphs.............(DEC)...... 20 Size in paragraphs.............(HEX)...... 0014 Size in bytes..................(DEC)...... 320 Location of environment........(Segment).. 0F47 Location of command processor..(Segment).. 0E86 Current command processor is primary...... YES The statistics display which follows the command indicates the status after the space has been added. If for any reason it is not possible to allocate all of the desired space, only that available will be allocated and the status display will reflect what was actually obtained. There is a practical limit to the size of the environment above which the system will not be able to use. That size is 2048 paragraphs or 32K. I should hope that would suffice! Any attempt to exceed that limit will result in only 2048 total paragraphs for the environment and a message being displayed. Additionally there is a limit imposed by the current version of ENVSIZE which you now have. Unfortunatly the method I used to perform this computerized "slight of hand" requires it to have enough free space contained in the program to place it's code above any action which would otherwise tend to corrupt it. To provide a version which would allow you to expand the Environment to it's full 32k in one shot would therefore require a program about 40K in size. This not only takes up disk space but makes it time consuming to transfer by modem. I promise that at some point in the future I will rewrite the code so that this will not be a problem. For the time, however, if you require more than 4k additional Environment space you will have to repeat execution of ENVSIZE. If any attempt is made to expand any environment other than the primary copy an informational message will be displayed and no action will be taken. For information on how to provide space in other copies of the Environment, read "Associated problems and bugs". d) Batch execution of ENVSIZE Due to the way ENVSIZE modifies the Environment size certain restrictions are placed on it's use within a batch file. To better understand why these restrictions exist read the "Technical Description" section which follows. Suffice it to say that I violated some basic rules of DOS which would allow corruption of the batch process should you not follow a few 12 rules. In essence the safest thing to do in a batch file after the ENVSIZE command is to chain (transfer execution) to another batch file or end the batch process. Thefollowing is an example of the safest way to use the ENVSIZE command in a batch file and is how my system boots up. File name: AUTOEXEC.BAT envsize 100 autoexe2 The AUTOEXE2 command executes a batch file called AUTOEXE2.BAT which continues by loading certain resident programs, setting the PATH and PROMPT parameters as well as those Parameters required by other programs I use and starting the DOS shell I use for hard disk management. When the whole process is complete I have everything set-up the way I like it, with a 1760 byte Environment. (the original 10 paragraphs + 100 new paragraphs * 16 bytes/paragraph = 1760) The rules you should follow when using ENVSIZE in a batch file are as follows: 1) Never follow the ENVSIZE command with a command which would add a Parameter to the Environment, such as the SET, PROMPT or PATH commands. 2) Do not follow the ENVSIZE command with a command which would result in the execution of another program. You are welcome to try this, but I don't guarantee the results. 3) Only follow the ENVSIZE command with either "INTERNAL" commands (those which can be executed entirely by the Command Processor, ie: DIR, CHDIR, etc.) or the name of another batch file. 13 4. Technical Description of ENVSIZE Simply put ENVSIZE reallocates the memory block associated with the Primary Environment, using DOS function 4A, to be of the desired size. As we know however, any program loaded after the Primary Command Processor will cause allocation of memory at the end of the Primary Environment preventing it from being expanded. This is therefore true with ENVSIZE. What I have done is to have ENVSIZE deallocate the memory associated with itself including it's Environment before reallocating the Environment space. This may seem to be a bit dangerous because it leaves the memory in which ENVSIZE is executing unallocated. But actually there is little which can cause trouble at that time unless there might happen to be a real strange resident program or driver running. When ENVSIZE then terminates, the operating system is left only to deallocate the memory which has already been deallocated, and there seems to be no trouble with that. Therefore the ENVSIZE scheme works. As usual there are some other problems to contend with and they are related to batch processes and Memory Allocation Blocks (MAB's). Both are somewhat related. When a batch process is used to call the ENVSIZE program, a small (4 to 6 paragraphs) block of memory is allocated for batch process housekeeping and it is located in the first available space past the Environment. This would prevent expansion of the Environment during batch processes and would severely limit the usefulness of this program. To circumvent this problem ENVSIZE simply deallocates that block of memory leaving it available for Environment space. The problem with this is that any unwanted modification of this area of memory would result in very unpredictable behavior. So this won't happen, the ENVSIZE program will not allow less than 15 paragraphs to be added, thus preventing an MAB entry from landing on top of that memory. This is also why there are some restrictions on the use of ENVSIZE in a batch file. For example, if enough new Parameters were then added, the area of memory used by the batch process would eventually be overwritten since it is now part of the Environment. When the batch process eventually terminates, or a new batch file is chained, this area will not be used any more except for Parameters. Problem solved. The other part of this problem is with the PSP and code for ENVSIZE itself. Since violation of that space could prove to be fatal it is protected by placing the start of the program code 4k up in the code segment. Along with the batch process space, the PSP is protected by the minimum number of paragraphs which ENVSIZE will allow to be added and the 256 paragraph maximum limit protects the code. Which is why I have decided to distribute this version with a 256 paragraph limit per execution. The size of ENVSIZE.COM is now about 10 Kbytes rather than the some 40 K which would be required to allow the full 2048 paragraphs in one shot. The compromise seems to be reasonable. I hope at some later time to have a version which relocates itself and would avoid that limitation. I realy don't want to wear out my welcome but there is one 14 more trivial thing. When a memory block is allocated it has placed in it the segment number of the parent program. So when ENVSIZE reallocates the Environment it, what you might say, adopts it. If that memory block was not un-adopted before ENVSIZE terminates it would be in danger of being lost (deallocated). To prevent this the parent segment number is returned to that of the Command Processor before termination. 15 5. Associated problems and bugs in DOS Just as a point of information and to facilitate better use of the Environment let me explain a little about the problems of using Parameters in MS-DOS. As I explained above, there is a way to provide space for Parameters in a copy of the Environment associated with a subsequent Command Processor (SHELL). I will describe this method and explain how to avoid a bug in the way the batch processor evaluates parameters. a) Providing Environment space in a SHELL Normally when a copy of the Environment is provided to a subsequent Command Processor it is provided with only as much space as is required by the Parameters it contains. Since it is not possible to expand that copy of the Environment, it must have been passed with DUMMY Parameters which are there simply to take up space. If in your AUTOEXEC.BAT file you use SET to include a number of these DUMMY Parameters you will always be able to delete them with the SET command and enter real Parameters. The following is a real example. Primary Environment before adding DUMMY C>set COMSPEC=C:\COMMAND.COM PATH=c:\;c:\dos Add the DUMMY Parameter C>set filla=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Environment with DUMMY Parameter C>set COMSPEC=C:\COMMAND.COM PATH=c:\;c:\dos FILLA=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Invoke a SHELL C>command The COMPAQ Personal Computer MS-DOS Version 3.10 (C) Copyright COMPAQ Computer Corp. 1982,83,84,85 (C) Copyright Microsoft Corp. 1981,82,83,84,85 16 Try to insert a Parameter C>set author=Charles P. Scott Out of environment space <- No space Remove the DUMMY Parameter C>set fillA= C>set author=Charles P. Scott C>set COMSPEC=C:\COMMAND.COM PATH=c:\;c:\dos AUTHOR=Charles P. Scott <- Took it this time I suppose you might ask why all this trouble. The answer lies with two particular situations. When the SHELL command is used from BASIC or a DOS SHELL is invoked by an application program the user is restricted by Environment limitations, especially with respect to batch file branching. Also there is a way to use a subsequent copy of the Command Processor COMMAND.COM to simulate subroutines in a batch file. But that is another subject which is addressed in several of the better MD-DOS books. b) Avoiding the batch Parameter evaluation bug Just in case you have not already run across the Parameter evaluation bug in MS-DOS I will describe it here and explain how to avoid it. The problem occurs when an IF statement is used to evaluate a parameter as shown here. IF %AUTHOR%==Charles P. Scott goto SKIP . . :SKIP . When the Parameter "AUTHOR" exists in the Environment the string "%AUTHOR%" is substituted with that Parameter's value. If It does not exist it is evaluated as "AUTHOR%", without the leading "%". Actually this is a benefit because it allows you to test for a non-existent Parameter as in the statement below. IF %AUTHOR%==AUTHOR% goto NOTFOUND 17 Well at least that is true up to my Compaq DOS version 3.1 where they have apparently tried to save face and ruined it for us. Now the nonexistent Parameter is evaluated to a null string (no characters) and will always produce a syntax error. IF ==Charles P. Scott goto SKIP That is how the line would try to execute in that version of DOS and would cause an error. With such a "correction" it becomes impossible to branch on a nonexistent Parameter without first eliminating all other possibilities! I hope that you have found this information of some value and not too much of a bore. Please don't hesitate to contact me if you have any comments on the above material or the program itself. Certainly if you find there to be some problems, let me know so that I can help you work them out or correct for them in future versions. 18 6. Registration with Team Alpha Once you have evaluated this program fill out the following form and send it to: Charles P. Scott / Team Alpha 519 Garden Springs Dr. Mt. Sterling, KY 40353 Or via Compuserve: 76556,3335 USER NAME____________________________________________________ COMPANY ____________________________________________________ ADDRESS ____________________________________________________ ____________________________________________________ ____________________________________________________ PHONE # (optional) __________________________________________ Equipment type, configuration and operating system ___________________________________________________________ ___________________________________________________________ Estimate of your computer skill level ___________________________________________________________ How you obtained a copy of ENVSIZE ___________________________________________________________ Comments and suggested enhancements ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ 19